Skip Headers

Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 13 Initialization Parameters

This chapter describes the initialization parameters that affect databases in a Data Guard environment.

Table 13-1 lists the initialization parameters and indicates if the parameter applies to the primary database role, the standby database role, or both. The table also includes notes and recommendations specific to setting the parameters in a Data Guard environment. Oracle Database Reference provides complete initialization parameter information, including how to update initialization parameters by issuing the `ALTER SYSTEM SET` or `ALTER SESSION` statements (for example, `ALTER SYSTEM SET LOG_ARCHIVE_TRACE`) or by editing the initialization parameter files. See the Oracle operating system-specific documentation for more information about setting initialization parameters.

Table 13-1 Initialization Parameters for Instances in a Data Guard Configuration

Parameter | Primary Role? | Standby Role? | Notes and Recommendations
--- | --- | --- | ---
`ARCHIVE_LAG_TARGET` = seconds | Yes | Physical only | Optional. Forces a log switch after the specified number of seconds elapses.
`COMPATIBLE` = release_number. | Yes | Logical and physical | Data Guard requires a minimum value of 9.2.0.1.0. Set to a minimum of 10.2.0.0 to use Oracle Database 10g new features. Specify the same value on the primary and standby databases if you expect to do a switchover. If the values differ, redo transport services may be unable to transmit redo data from the primary database to the standby databases. See Section 3.2.3 for an example. For rolling upgrades using SQL Apply, set this parameter according to the guidelines described in Section 11.4, "Prepare to Upgrade".
`CONTROL_FILE_RECORD_KEEP_TIME` = number_of_days | Yes | Logical and physical | Optional. Use this parameter to avoid overwriting a reusable record in the control file (that contains needed information such as an archived redo log file) for the specified number of days (from 0 to 365). See Section 5.7.4.
`CONTROL_FILES` = 'control_file_name' , control_file_name', '...') | Yes | Logical and physical | Required. Specify the path name and filename for one or more control files. The control files must already exist on the database. Oracle recommends using 2 control files. If another copy of the current control file is available, then an instance can be easily restarted after copying the good control file to the location of the bad control file. See Section 3.2.3 for an example.
`DB_FILE_NAME_CONVERT` = (location_of_primary_database_datafile' , 'location_of_standby_database_datafile_name' , '...' | No | Physical only | Required if the standby database is on the same system as the primary database or if the directory where the datafiles are located on the standby system is different from the primary system. This parameter must specify paired strings. The first string is a sequence of characters to be looked for in a primary database filename. If that sequence of characters is matched, it is replaced by the second string to construct the standby database filename. You can specify multiple pairs of filenames. See also Example 3-3.
`DB_UNIQUE_NAME` = unique_service_provider_name_for_this_database | Yes | Logical and physical | Recommended, but required if you specify the `LOG_ARCHIVE_CONFIG` parameter. Specifies a unique name for this database. This name does not change even if the primary and standby databases reverse roles. The `DB_UNIQUE_NAME` parameter defaults to the value of the `DB_NAME` parameter. See also the `LOG_ARCHIVE_CONFIG` parameter and Section 5.4.2.
`FAL_CLIENT` = Oracle_Net_service_name | Yes | Physical only | Required if the `FAL_SERVER` parameter is specified. Specifies the Oracle Net service name used by the FAL server (typically the primary database) to refer to the FAL client (standby database). See Section 5.8.3.
`FAL_SERVER` = Oracle_Net_service_name | No | Physical only | Required if the `FAL_CLIENT` parameter is specified. Specifies one or more Oracle Net service names for the databases from which this standby database can fetch (request) missing archived redo log files. See Section 5.8.3.
`INSTANCE_NAME` | Yes | Logical and physical | Optional. If this parameter is defined and the primary and standby databases reside on the same host, specify a different name for the standby database than you specify for the primary database. See Section 3.2.3 for an example.
`LOG_ARCHIVE_CONFIG='DG_CONFIG=(`db_unique_name, db_unique_name, ...)' | Yes | Logical and physical | Recommended. Specify the `DG_CONFIG` attribute to identify the `DB_UNIQUE_NAME` for the primary database and each standby database in the Data Guard configuration. The default value of this parameter enables the primary database to send redo data to remote destinations and enables standby databases to receive redo data. The `DG_CONFIG` attribute must be set to enable the dynamic addition of a standby database to a Data Guard configuration that has a Real Application Clusters primary database running in either maximum protection or maximum availability mode. See Section 5.4.2.
`LOG_ARCHIVE_DEST_``n` = `{LOCATION=`path_name| `SERVICE=`service_name, attribute, attribute, ... } | Yes | Logical and physical | Required. Define up to ten (where n = 1, 2, 3, ... 10) destinations, each of which must specify either the `LOCATION` or `SERVICE` attribute. Specify a corresponding `LOG_ARCHIVE_DEST_STATE_``n` parameter for every `LOG_ARCHIVE_DEST_``n` parameter. See Section 5.2.2 and Chapter 14 for more information.
`LOG_ARCHIVE_DEST_STATE_``n` = {`ENABLE`|`DEFER`|`ALTERNATE`|`RESET`} | Yes | Logical and physical | Required. Specify a `LOG_ARCHIVE_DEST_STATE_``n` parameter to enable or disable redo transport services to transmit redo data to the specified (or to an alternate) destination. Define a `LOG_ARCHIVE_DEST_STATE_``n` parameter for every `LOG_ARCHIVE_DEST_``n` parameter. See also Section 5.2.2 and Chapter 14.
`LOG_ARCHIVE_FORMAT`=log%d_%t_%s_%r`.arc` | Yes | Logical and physical | Required if you specify the `STANDBY_ARCHIVE_DEST` parameter. These parameters are concatenated together to generate fully qualified archived redo log filenames on the standby database. See also Section 5.7.1.
`LOG_ARCHIVE_LOCAL_FIRST =[TRUE|FALSE]` | Yes | No | Optional. Specify to control when archiver processes (ARCn) transmit; either after (`TRUE`) the online redo log file was successfully archived to at least one local destination, or at the same time (`FALSE`) the online redo log file is being archived to local destinations. See also Section 5.3.1.
`LOG_ARCHIVE_MAX_PROCESSES` =integer | Yes | Logical and physical | Optional. Specify the number (from 1 to 30) of archiver (`ARC` n) processes you want Oracle software to invoke initially. The default value is 4. See Section 5.3.1.2 for more information about `ARC` n processing.
`LOG_ARCHIVE_MIN_SUCCEED_DEST`=integer | Yes | No | Optional. Define the minimum number (from 1 to 10) of destinations that must receive redo data successfully before the log writer process on the primary database can reuse the online redo log file.
`LOG_ARCHIVE_TRACE`=integer | Yes | Logical and physical | Optional. Set this parameter to trace the transmission of redo data to the standby site. The valid integer values (0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, or 4096) are described in Appendix G.
`LOG_FILE_NAME_CONVERT='`location_of_primary_database_redo_logs', 'location_of_standby_database_redo_logs' | No | Logical and physical | Required when the standby database is on the same system as the primary database or when the directory structure where the log files are located on the standby site is different from the primary site. This parameter converts the path names of the primary database online redo log file to path names on the standby database. See Section 3.2.3 for an example.
`PARALLEL_MAX_SERVERS=`integer | Yes | Logical only | R``equired. Specify the maximum number of parallel servers working on the logical standby database. This parameter must not be set to a value less than 5 on a logical standby database. For best results, set `PARALLEL_MAX_SERVERS` to a minimum of 9.
`REMOTE_LOGIN_PASSWORDFILE`= {`EXCLUSIVE`|`SHARED`] | Yes | Logical and physical | Required. Specify on the primary and all standby databases.
`SHARED_POOL_SIZE =` bytes | Yes | Logical and physical | Optional. Use to specify the system global area (SGA) to stage the information read from the online redo log files. The more SGA that is available, the more information that can be staged.
`SORT_AREA_SIZE =` bytes | Yes | Logical and physical | Optional. Increase the `SORT_AREA_SIZE` size (default size is 65536 bytes) to improve the efficiency of large sorts. See also Section 8.2.
`STANDBY_ARCHIVE_DEST=` filespec | No | Logical and physical | Optional. Specify the location of archived redo log files received on the standby database from the primary database. The `STANDBY_ARCHIVE_DEST` initialization parameter overrides the directory location specified with the `LOG_ARCHIVE_DEST_``n` parameter. `STANDBY_ARCHIVE_DEST` and `LOG_ARCHIVE_FORMAT` are concatenated to generate fully qualified log filenames. See Section 5.7.1.
`STANDBY_FILE_MANAGEMENT =` {`AUTO`|`MANUAL`} | Yes | Physical only | Set the `STANDBY_FILE_MANAGEMENT` parameter to `AUTO` so that when datafiles are added to or dropped from the primary database, corresponding changes are made in the standby database without manual intervention. If the directory structures on the primary and standby databases are different, you must also set the `DB_FILE_NAME_CONVERT` initialization parameter to convert the filenames of one or more sets of datafiles on the primary database to filenames on the (physical) standby database. See Example 3-3 for more information and examples.
`USER_DUMP_DEST =` directory_path_name_of_trace_file | Yes | Logical and physical | Required if you specify the `LOG_ARCHIVE_TRACE` parameter. The `USER_DUMP_DEST` specifies the path name for a directory where the server will write debugging trace files. See Appendix G.